When a client connects to a server on a network and begins a session, there can be information stored on the server that is particular to that client session. For example, a user of the client might place items in a virtual shopping cart. The selection of those items can be stored, at least temporarily, on the server. In this example, there is no need for other users or servers to have access to this information. It is desirable, however, that this data be highly available across a network or server cluster such that if the server storing the session data fails, it is possible to recover the data on another server.
One way to accomplish data recovery in such a situation is to store the information in a database during the session, although the information could also be stored by other means such as in a data file. Every time a change is made to the session data, an update is written to the database such that the data is accessible to every server having access to the database. The data is stored in a persistent place, and can easily be retrieved by another server.
A problem exists with this approach, however, in that it is fairly expensive to fetch session information from the database for each request. The multiple hits to the database can create a bottleneck and bog the system down to the point where it is basically inoperable, as the throughput of the system can depend on the number of database connections from the server. Also, these sessions may contain the type of information, to which users want quick access. With some applications, it is possible for there to be thousands of clients working simultaneously, resulting in thousands of concurrent sessions. Some servers are expected to host many different applications, which further increases the number of sessions that may need to be hosted.
It is desirable to improve the speed and efficiency of such a system so that these tens of thousands of users may use the system effectively. One way to avoid such a bottleneck is to assume that the servers will be up and running 99.9% of the time and simply neglect to backup any information. This may be the solution providing the fastest user experience, but even 0.1% downtime resulting in data loss is unacceptable to many users.